IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media that it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 8). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly. The integration of an IP Multimedia Subsystem into a 3G mobile communications system is illustrated schematically in FIG. 1.
IMS Authentication and Key Agreement (AKA) is used to establish shared keys between a User Equipment (UE) 101 such as a mobile telephone, and a Proxy-Call Session Control Function (P-CSCF) 102 in an IMS network 103. This allows signals sent between the UE 101 and the IMS network 103 to be securely encrypted by using an IP-sec tunnel with pre-shared keys. The P-CSCF 101 may be located either in a Visited Public Land Mobile Network (PLMN), as illustrated in FIG. 2, or in a Home PLMN, as illustrated in FIG. 3. The Home PLMN 201 is a network in which a UE 202 is registered, and the Visited PLMN 203 is a network to which the UE 202 may be attached. A Serving-Session Control Function (S-CSCF) 204 is located in the Home PLMN 201, and controls authentication and authorization of the UE 202 when the UE joins the network, see, for example, TS 33.203.
It is envisaged that IMS will not only apply to 3GPP IMS networks but to non-3GPP IMS networks such as Telecoms & Internet converged Services & Protocols for Advanced Networks (ETSI TISPAN) and PacketCable, see, for example ETSI ES 282 007 and PKT-SP-23.228-I02-061013. However, TISPAN and PacketCable deployments of IMS do not only use IMS AKA, as used by 3GPP IMS networks. Authorising a Universal Subscriber Identity Module (USIM) or an IP Multimedia Services Identity Module (ISIM) in a TISPAN or PacketCable terminal to access a 3GPP IMS network is, in certain scenarios, an obstacle for these access technologies. TISPAN and PacketCable have introduced other security solutions as HTTP Digest for SIP, Network Attachment Subsystem (NASS)-IMS bundled authentication, and Transport Layer Security (TLS). However, these security mechanisms offer a lower level of security that IMS AKA.
It is desirable for 3GPP IMS networks to be capable of inter-working with TISPAN and PacketCable networks, to improve the options available to users of the networks. In order to allow this, the S-CSCF in an IMS network must be able to handle and support inter-working between different access technologies. This would allow terminals using different access technologies to communicate with each other.
In addition to IMS networks being accessible using different access technologies, such as 3GPP, TISPAN, and PacketCable, IMS networks may also be accessible using interconnect technologies such as PSTN inter connect (see, for example, 3GPP TS 23.002), IMS interconnect (see, for example, 3GPP TS 23.228), and Internet Interconnect. Note that: Internet Interconnect is not a specified protocol or system, and tends to be based on proprietary implementations. These allow terminals accessing a non-IMS network to access IMS services from an IMS network.
The different types of network and access technologies expose an IMS network to signalling from terminals or network nodes from different networks, that may have different trust levels to other nodes within the same IMS network. This is a particular problem for IMS interconnect, as it is not possible for an interconnecting network to have any knowledge about different trust levels used in another network with which it is interconnected. The interconnecting network will therefore treat all incoming traffic equally.
In current IMS networks, there is only one trust domain accorded to signalling, and so a message is either trusted or it is not trusted. If a SIP Request used to establish a session is not trusted, then an asserted user identity, P-Asserted-Id (see RFC3325), contained in the SIP Request is removed from the SIP Request before being forwarded to the non-trusted domain. The IMS network operator must either accept the lower level of security used e.g. early IMS security (see TR33.978) or HTTP Digest (see RFC2617), or not accept it and remove any asserted information from the request.
IMS provides very strong security, but as interoperability with other access technologies and networks increases then the security applied to IMS communications may be lowered. This leads to an increased risk of unsolicited communications to each IMS user, which is unsatisfactory. It can also reduce the likelihood of IMS being adopted for services requiring a strong security architecture, such as IPTV where media streams may be encrypted to individual users or groups of users.